Super-nitpick: I think template variable substitution has to take place before relative URI-reference resolution, so perhaps reverse these?

I think template variable substitution has to take place before relative URI-reference resolution

Why?

And, how? If the URI is relative (it hasn't been resolved to an absolute URI yet) then trying to match it against an absolute URI from the HTTP request will fail. You need the whole thing to match against.

Because it's possible to write a templatized URI reference that will resolve differently depending on how the template is filled out. For example, I don't believe we forbid / in expanded server URL variables like we do in path ones, and even if we do forbid it, there are at least several different ways this could play out:

{start}/foo

• simple/foo (relative path reference)
• example.com/foo (scheme-relative refrence)
• https://example.com/foo (full URI)
• /absolute/foo (absolute path, assuming / is valid)

You can't tell how to resolve the reference until the variables have been expanded.

Again though, you can't match a URI to a template pattern, to figure out what the values of those template variables should be, until the entire pattern is present.

Clearly the entire concept of server urls needs to be rethought, or some extra restrictions added, to make this actually workable in reality.

While thinking through this more I also realized that server urls (and path templates too) should probably be ascii-only (even more restrictive than that actually as the list of permitted characters is a subset of ascii) if we ever expect them to match against a URI - i.e. all other characters should be %-url-encoded. We lost this when we removed the "format": "uri-reference" on server urls in order to accomodate { and }.

@karenetheridge I'm happy to drop the point as I don't have time in the next few weeks to delve into that level of detail. And really, the issue here is the ambiguity of the process and not the word order, which is not written in a way that forces one order or the other. It might be that different scenarios work better with different orders.

Anyway, I'm withdrawing any objection, TSC feel free to merge with two approvals.

@handrews If you can concoct some examples of OAD snippets + HTTP request URIs that should match in a certain way (or not match), I can run them through my code and reason through how they behave; I am struggling to find concrete examples that would demonstrate the ambiguity here.

(I'm also still pondering whether we need to explicitly state that path templates and server url templates MUST (SHOULD?) be url-encoded (sans the un-encoded curly braces of course) or not in order to be sure of proper matching. Something to spin off into a discussion perhaps.)